chdkfandomcom-20200222-history
HF10/100 Firmware Analysis
Official Firmware Update There's an official firmware update available which updates version 1.0.0.0 to 1.0.1.0, and you need to fill in your serial number at the official Canon download site. Where and how to get the firmware and a serial number: http://chdk.setepontos.com/index.php/topic,1641.0.html Another update for version 1.0.2.0 http://web.canon.jp/imaging/dcp/firm-e/hf10/index.html Encryption The update file is encrypted with a 0x1040 XOR key, derived from 300D still camera keys. Search for the decoder in the above topic. The key calculation works as follows, where key1 is the 512byte 300D key, and key2 is the 513byte 300D key: do decode 64 bytes, begin with key1[ 0] and key2[ 0] decode 1 bytes, begin with key1[ 0] and key264 decode 63 bytes, begin with key1[ 1] and key2[ 0] decode 2 bytes, begin with key1[ 0] and key263 decode 62 bytes, begin with key1[ 2] and key2[ 0] decode 3 bytes, begin with key1[ 0] and key262 decode 61 bytes, begin with key1[ 3] and key2[ 0] decode 4 bytes, begin with key1[ 0] and key261 . . . decode 2 bytes, begin with key162 and key2[ 0] decode 63 bytes, begin with key1[ 0] and key2[ 2] decode 1 bytes, begin with key163 and key2[ 0] decode 64 bytes, begin with key1[ 0] and key2[ 1] while decodedbytes != 0 It uses only the first 64 respectively 65 bytes of the keys, and the resulting key is 4160 bytes long (0x1040). You can find an universal firmware de-/encrypter here: http://chdk.setepontos.com/index.php/topic,1641.msg27029.html#msg27029. It can crypt all known firmware versions (HF10/100 and HV30 automatically recognized), recalculate checksums and optionally split the file into its sections. File Structure Here's general description of the structure of an update file: The checksum is a simple uint32 sum of all uint32's in the corresponding section. Version 1.0.1.0 This update consists of 2 sections. Content Overview * 0x0 - 0x200000 First section, including the first unencrypted 0x10010 bytes; MIPS * 0x200000 - 0x7F7364 Second section ** 0x20 length header for this section. Contains this section size: 0x5f7344 bytes ** >= 0x200020 - ROM&RAM data; M32R * 0x2C footer Interesting Addresses * 8bit monochromatic bitmaps These bitmaps consist of a 2-byte header containing the bitmap width (first byte) and the width that the bitmaps gets stretched to when displayed. The bitmaps are always 18 pixels high and aligned to 4 bytes. All fonts are included as well. ** 0x10608C - 0x14049C ** 0x142CA4 - 0x179A8C * bitmap lookup table, referenced from m32r code ** 0x5EFC34 - 0x5F3433 * The same bitmaps as before can be found a second time, this time aligned at 2 bytes. ** 0x5F3434 - 0x663C46 * color palette A color is 32bits long, in the format 0xRRGGBBAA. The mapping between this palette and the bitmaps is unknown, if there even exists one. ** 0x669234 - 0x66A0A0 * Video VBR compression rates http://chdk.setepontos.com/index.php/topic,1641.msg19665.html#msg19665 There are 5 presets, each consisting of 6 2-byte big endian values ** 0x46BCF8 - 0x46BD34 Update Process To detect a valid firmware update file, the camera does the following: # VEE1-9.FIM At first it looks for this file, in descending order (9 to 1). This file is detected as a firmware file if a valid header exists, and only in this case the firmware update button in the OSD menu gets enabled. # Version number check The version number of the firmware update file gets compared to the camera's actual version. You need an increased number to update the camera, else it prints an error message. # Checksum check After passing the version number check, the camera takes some seconds to verify the checksum(s). if it succeeds, the firmware gets updated and the camera restarts, else you get the message ""Firm Update Error! Check the card.". Processor and architecture The HV10/100 contains 2 processor cores, one of the Renesas M32R family, and a MIPS. M32R The processor is of M32R family (Mitsubishi, now Renesas) Documentation: * e32rsm.pdf - Instruction reference * 32182um.pdf/e32172um.pdf - Chip architecture The exact processor and peripherial models are unknown, however the code shows that CR5 (EIT Vector Base) register is used - and this register seems to be present only in M32R2 processors. Code location The M32R section should be loaded at 0x04000000 location. Initialization routine starts up at 0x04000000 (reset interrupt). The MIPS section seems to be mapped to the address 0xBFA00000. DATA location No clear location for the data section is found yet, but it starts averagely at 0x04306B20, and then moved to the destination location at 0x4C8A6840. This gives all valid string and data references. RAM location No clear understanding yet - most probably a free usage RAM comes after the data (0x4C8A6840 and above) Special locations Many of peripherial IO ports, etc. Some are documented in Renesas PDFs, but they seems not to be the same for our case. Things to do * Processor model. No documentation for M32R'2' ? * Bootstrap understanding (some section init/movements should be there) * TRAP 7/8 usage (system calls?) * stdlib exploration * No information on how to detect OS related calls (tasks, sems, etc.) * Which os (could be not dryos, but MR32R)? Category:Camcorders